Payment Processing Using Electronic Benefit Transfer (EBT) System

ABSTRACT

Systems and methods are described for incorporating electronic benefit transfer (EBT) systems into a secure, mobile, and electronic payment processing system. Existing EBT systems capture data regarding a purchase. This record keeping functionality can be harnessed to provide retailers and marketers with data regarding marketing efforts, coupon use, and more. A mobile device can be used to interact with a presence detection system. Coupons or payment information can be received at a mobile device, and payments can be carried out between a mobile device and a points of sale (POS).

CROSS REFERENCE TO RELATED INFORMATION

This application is a continuation of U.S. application Ser. No.15/386,974, filed Dec. 21, 2016; which claims the benefit of U.S.Provisional Patent Application No. 62/270,279, filed Dec. 21, 2015, bothtitled, “Payment Processing Using Electronic Benefit Transfer (EBT)System”, the contents of which are hereby incorporated herein in itsentirety.

TECHNICAL FIELD

The present disclosure is directed to electronic payment processing andoffer systems, and more specifically to making and redeeming offers in asecure, mobile electronic payment processing system.

BACKGROUND OF THE INVENTION

A common problem in commerce and advertising is that sending bulkads/offers is cheap but of limited effectiveness and theseller/manufacturer usually cannot interact with the consumer orcustomer. On the other hand, if a store hires numerous sales people, ahigh level of interaction can be achieved with consumers, but suchpractices are expensive. Retailers would love to know various indicatorsof consumer behavior: whether consumers buy certain products on aregular basis, how often, what quantities, in combination with whatother products, at what stores, what coupons work, etc. The more data aretailer has, the more it can target its marketing or advertisingefforts toward methods that show the greatest return on investment.Retailers have a need for tools for marketing and selling that providehigh levels of interaction with customers while at the same time beinginexpensive. This can also help direct ads toward customers thatactually want to see them.

BRIEF SUMMARY OF THE INVENTION

One possible embodiment of the present disclosure comprises a system forallowing a consumer to complete a payment transaction with a merchant ata merchant location, the system comprising: a detection unit operable todetect a mobile device associated with the consumer; a remote server incommunication with the detection unit, the remote server used to verifyan identity of the consumer using the mobile device and to form avirtual payment account number, wherein the virtual payment accountnumber is associated with a coin, the coin acting as an identifier for atransaction between the merchant and consumer and is specific to thepayment transaction, the remote server further operable to send paymentauthorization information to the consumer's mobile device to allow theconsumer to initiate a payment transaction with the merchant; and an EBTpoint of sale terminal used to process the payment transaction at therequest of the consumer, processing the payment transaction using theauthorization information, wherein the authorization information isassociated with the virtual payment account number and the virtualpayment account number is used by the merchant as a mechanism forpayment using an EBT payment processing system for the purpose ofidentifying each item purchased by the consumer.

Another possible embodiment of the present disclosure comprises a systemfor allowing a consumer to complete a payment transaction with amerchant at a merchant location, the system comprising: a detection unitoperable to detect a mobile device associated with the consumer; aremote server in communication with the detection unit, the remoteserver used to verify an identity of the consumer using the mobiledevice and to form a virtual payment account number, the remote serverfurther operable to send the virtual payment account number to themobile device; and an EBT point of sale terminal used to process thepayment transaction at the request of the consumer; wherein the systemprocesses the payment transaction using the virtual payment accountnumber as a mechanism for payment using an EBT payment processing systemfor the purpose of identifying each item purchased by the consumer.

Another possible embodiment of the present disclosure comprises a methodof allowing a consumer to complete a payment transaction with a merchantat a merchant location, the method comprising: receiving a notificationthat a mobile device associated with the consumer is at a location;verifying an identity of the consumer using the mobile device; forming avirtual payment account number, wherein the virtual payment accountnumber is associated with a coin, the coin acting as an identifier for atransaction between the merchant and consumer and is specific to thepayment transaction; and sending payment authorization information tothe consumer's mobile device to allow the consumer to initiate a paymenttransaction with the merchant; wherein a point of sale terminal is usedto process the payment transaction using the authorization informationat the request of the consumer, wherein the authorization information isassociated with the virtual payment account number and the virtualpayment account number is used by the merchant as a mechanism forpayment using an EBT payment processing system for the purpose ofidentifying each item purchased by the consumer.

The foregoing has outlined rather broadly the features and technicaladvantages of the present invention in order that the detaileddescription of the invention that follows may be better understood.Additional features and advantages of the invention will be describedhereinafter which form the subject of the claims of the invention. Itshould be appreciated by those skilled in the art that the conceptionand specific embodiment disclosed may be readily utilized as a basis formodifying or designing other structures for carrying out the samepurposes of the present invention. It should also be realized by thoseskilled in the art that such equivalent constructions do not depart fromthe spirit and scope of the invention as set forth in the appendedclaims. The novel features which are believed to be characteristic ofthe invention, both as to its organization and method of operation,together with further objects and advantages will be better understoodfrom the following description when considered in connection with theaccompanying figures. It is to be expressly understood, however, thateach of the figures is provided for the purpose of illustration anddescription only and is not intended as a definition of the limits ofthe present invention.

BRIEF DESCRIPTION OF THE DRAWINGS

For a more complete understanding of the present invention, reference isnow made to the following descriptions taken in conjunction with theaccompanying drawings, in which:

FIG. 1 is a diagram of a possible embodiment under the presentdisclosure.

FIG. 2 is a flow-chart diagram of a possible embodiment under thepresent disclosure.

FIGS. 3A-3B are flow-chart diagrams of possible embodiments under thepresent disclosure.

FIG. 4 is a flow-chart diagram of a possible embodiment under thepresent disclosure.

FIG. 5 is a flow-chart diagram of a possible embodiment under thepresent disclosure.

FIG. 6 is a flow-chart diagram of a possible embodiment under thepresent disclosure.

FIG. 7 is a flow-chart diagram of a possible embodiment under thepresent disclosure.

FIG. 8 is a flow-chart diagram of a possible embodiment under thepresent disclosure.

FIG. 9 is a flow-chart diagram of a possible embodiment under thepresent disclosure.

FIG. 10 is a diagram of a possible embodiment under the presentdisclosure.

FIG. 11 is a diagram of a possible embodiment under the presentdisclosure.

FIGS. 12A-12C are diagrams of possible embodiments of virtual paymentaccount numbers under the present disclosure.

FIG. 13 is a flow-chart diagram of a possible embodiment under thepresent disclosure.

FIG. 14 is a flow-chart diagram of a possible embodiment under thepresent disclosure.

DETAILED DESCRIPTION OF THE INVENTION

When consumers present a payment card at a retailer's point-of-sale(POS) terminal, they are generally asked what type of card is beingpresented, for example, a credit card, debit card, gift card, etc. Thetype of card determines the payment processing network used by the POSterminal or retailer network that is used to process the payment. Eachtype of card uses a different payment network and process. One type ofpayment network that is available, particularly at grocery stores anddrug stores, is an electronic benefit transfer (EBT) system. Thesesystems can be associated with benefits that are distributed through theSupplemental Nutrition Assistance Program (SNAP), formerly the FoodStamp Program or Temporary Assistance for Needy Families (TANF). Sincethese programs have restrictions on what can be bought with thebenefits, any payment using an EBT card has to be examined in real timeat the time of purchase to ensure that only approved items are paid forusing the benefits. To make this determination, the EBT payment processincludes both the payment information and information on all of theitems being purchased. This information is sent to an EBT processorwhich approves or denies each item based on the program rules. While EBTtransactions are currently only associated with benefit programs,embodiments under the present disclosure use the EBT payment process tocapture a customer's shopping cart or purchase receipt information,identifying all of the items purchased by the consumer during thattransaction. This information may be captured by retailers using rewardprograms and the like.

The present teachings provide a payment and marketing system allowingconsumers to access a variety of payment options via a mobile device,and for retailers and companies to interact directly with consumers. Thepresent teachings may make use of virtual payment account numbers(VPANs) and related payment technology, such as set forth in UnitedStates Patent Application Publication Nos. 2014/0114780, 2012/0101887,and 2014/0040001, which are incorporated herein by reference.

The present teachings allow various entities to interact with theconsumer and bring the consumer value. For example, a manufacturer canengage consumers, by sending coupons or offers that can be redeemed at avariety of retailers. Other financial entities may be able to offercoupons or other deals to consumers as well. For example a credit cardcompany may desire to promote some product or store. The financialpayment processing entity can interact with both consumers, retailers,and other financial entities such as credit cards, as the financialpayment processing entity interacts and interfaces with all thesegroups. Furthermore, marketing entities may be able to analyze dataregarding consumer behavior. Marketing entities can be marketingdivisions of the entities listed above, or they may be contractedmarketing companies that are contracted to analyze the data collected.Each involved party must have contractual permission to access data thatthey receive. A customer may have to consent to data collection in theterms and conditions associated with downloading a mobile application.Furthermore, a customer, once the application is installed, will have toassociate various payment methods (money sources) with theapplication/device. Doing so may require further acceptance of terms andconditions. The customer can sell their information for the coupons andother financial incentives that they will receive.

One embodiment of the present teachings is a system and method forproviding customers with a variety of payment options, accessed via amobile device or application, when the customer wishes to pay at aretail location. Whatever payment source or method the customer chooses,a VPAN or other number can be generated to match the type of paymentaccepted by the retailer. The system can also make use of a coin,described further below.

The system and methods described herein can combine these paymenttechnologies (VPAN and/or payment coins) with the EBT (electronicbenefits transfer) card technology. EBT allows a receipt or purchaserecord to be sent to various contracted parties, allowing greatertracking of customers and allowing study of consumer behavior. Forexample, some POS (point of sale) devices already work with EBT cards,in most cases POS devices in grocery stores and other establishments. Asdescribed, EBT cards are commonly used for government programs whereinrecipients can use EBT cards to purchase food or other goods. Oftentimesrecipients are prohibited from using EBT cards to purchase certainitems, such as alcohol. As such EBT POS units are capable of receivingand sending data regarding purchased items, also referred to as the“shopping cart.” The current teachings expand upon the VPAN, coin, andEBT technologies. The EBT functionality of reporting on a shopper'sshopping cart can be harnessed to provide retailers or other advertisersaccess to the shopping cart as a means of studying the effects ofvarious marketing efforts. When combined with the payments systems suchas VPAN or coin, an advertiser or retailer can have a view of acustomer's behavior from beginning to end, from entering a store orreceiving an offer until payment.

FIG. 1 shows a possible system embodiment 100 under the presentdisclosure. In system 100, a consumer 105 may enter a store or otherlocation 130. A detection device 115 at location 130 can detect consumer105 by their mobile device 110. Detection device 115 can communicate bywireless or wired communication with application servers 180. Consumer105 will preferably have previously registered with application servers180 (such as user 160 using computer 168 or mobile device 165). Consumer105 will preferably have downloaded and installed a payment applicationor marketing application on mobile device 110. When detection device 115detects mobile device 110 the application servers 180 can respond bysending coupons, offers, or other communications to mobile device 110.Alternately, application servers 180 can perform an identityverification with consumer 105 by requesting a password, thumbprint, orother information. Verification may alternatively involve exchanginginformation with the mobile device. Application servers can send paymentinformation to mobile device 110 for use in paying for a transaction atlocation 130. Payment information can comprise a virtual payment accountnumber (“VPAN”, described further below). Payment information can alsocomprise a portion of a VPAN, an entire VPAN, information related to acoin (described below), an electronic benefit transfer (EBT) number, anEBT VPAN, or other information. Part of the payment information can besent to point of sale (POS) terminal 120. Application servers 180 cancontinue to send coupons, offers, or other information to consumer 105before, during, or after, the consumer's visit to location 130.Application servers may have access to a variety of funding sources 185.Funding sources 185 may comprise bank accounts, credit cards, EBTaccounts, loyalty points, prizes, or other sources. Application servers180 may allow consumer 105 to select a funding source for purchases madeat location 130 or at other locations. When making a purchase, consumer105 may approach POS terminal 120. Payment can be accomplished byproviding a payment code or a portion thereof. POS terminal 120 canreceive the payment information and institute a payment operation. Apayment operation may include sending payment and purchase informationto EBT servers 170. Application servers 180 may also be involved inpayment approval or other aspects of a purchase. Credit card approval,debit card approval, may also be involved. EBT servers 170 may provideapproval for the purchase or simply record data from the purchase. Datasaved by EBT servers can include consumer identification information,purchased items, prices, coupons, discounts, funding sources, date,time, location and more. EBT servers 170 can save such information orsend it to application servers 180. Application servers 180 can use suchdata to perform analytics regarding marketing and advertising or othercriteria. Communication among the various components of system 100 cancomprise wireless or wired communication. POS terminal 120 and detectiondevice 115 can comprise wired connections 122, 123 to network 150 ordirectly to EBT servers 170. They can also comprise wireless interfacesfor Wi-Fi, cellular, or any appropriate wireless network. Variouswireless networks such as cellular 158, satellite 155, or others can beimplemented as part of system 100. Mobile devices can comprisesmartphones, cellphones, tablets, smartwatches, and other devicescapable of wireless communication.

EBT servers 170 can comprise a variety of servers, computers, networkconnections, and other hardware and software components in an EBTpayment processing system. EBT servers 170 can comprise portions of apre-existing EBT system. EBT systems can be useful because of theirability to capture information about a purchase. This functionality canbe useful as application servers 180 may be used by a retailer tomonitor and analyze sales and marketing data. Instead of, or in additionto, installing brand new hardware and purchase tracking tools, apre-existing EBT system can be utilized to capture, store, or trackdata.

FIG. 2 shows one embodiment of a payment processing system under thepresent teachings. As shown, the customer can pull funds from anyavailable money source, and using the systems and methods described cancomplete the payment using EBT and an EBT compatible POS device. Thepresent teachings include systems and methods for taking advantage ofthe POS capabilities of EBT systems. As described above, VPANs can beused to convert a customer's desired money source into a one-time usedigital card that can pay a merchant in the merchant's desired type offunds. Similarly, the present teachings can take any of a user's moneysources and convert it into an EBT style payment that records thepurchases made and sends a receipt or report to a retailer, seller,advertiser, etc.

FIG. 2 displays a possible embodiment whereby a customer could registerand pay for merchandise using a VPAN or coin system. At step 1, acustomer registers and accepts terms and conditions. At step 2 thepayment method is set up. At step 3, a customer's presence is detectedat a retail location via any of a variety of methods. At step 4,preparation is made for a purchase, an offer is selected and a paymentmethod is selected. At step 5 the consumer checks out with a cashier ata POS. At step 6 funding is completed for the transaction by capturingthe selected payment. At step 7 a back end analysis can be completed,such as recording the purchases and studying consumer preferences orbehavior. FIGS. 4 and 5 show further embodiments of the processdisplayed in FIG. 2.

Using the aggregate data, the retailer, or whatever entity receives thepurchase data, will be able to study various aspects of customer data.For example, customers may react differently to shirt coupons than topants coupons. Or results may vary significantly between 5% or 10%coupons than to 20%—more than would be expected given the differentamounts. Women and men may react differently to different coupons. Orwomen and men may use different money sources with different frequency.Customers may react differently to coupons depending on time of day orday of the week or time of the year.

In various embodiments, a consumer may have several different sources offunds: credit cards, debit cards, gift cards, loyalty cards, rewardcards or others. A consumer, at any given time, may have access to allor a subset of these types of funds. Or a consumer may wish to redeemloyalty or rewards points instead of paying cash. Possibly a consumer'scredit card carries a high balance, so the consumer wishes to use asecond or third credit card. For various reasons, a consumer would liketo have access and options to use a variety of fund sources whenshopping. However, a retailer may only accept certain types of payments.For example, a store may wish to only accept cash, debit cards, andstore-branded charge cards. If a consumer wanted to use a certain creditcard, or to use some type of loyalty points, in the past she might notbe able to do so. The present teachings allow the consumer to use herpayment of choice.

Referring again to FIG. 2, other aspects can be described of the systemand method shown. The method 40 preferably begins by registering newconsumer(s) 41 before the consumer(s) can enter into transactions usingthe system, as shown by step 42. The new consumer 41 creates an accountand supplies information such as name, address, phone and otheridentifying information. In addition, at the time of sign up, theconsumer 41 can agree to terms and conditions for use of the system andservice and register a payment card as shown in step 43 used to fund theconsumer portion of transactions. The payment card may be validated bythe system and may be checked for availability of funds.

Next, the system 49, which can be connected to persistent storage 50,may require, prior to use, that merchants 52 who desire to use thesystem also register. The merchant provides their physical address,trade name, and business name, as well as a phone number and othermerchant-specific information. The information provided by the merchantcan also be verified through other sources such as a Google® search aswell as a physical GPS location provided by an independent source. Theverification methods would help prevent fraudulent merchant accounts.

The merchant then can create an offer account by which the merchant canfund offers that the system herein presents to consumers and that arefulfilled at their stores resulting in the specific location receivingfunds from both the consumer and from the offer account. The offeraccount can contain the merchant's funds, that are accessible by theservice to fulfill transactions. The offer methodology and process willbe described in greater detail with respect to FIGS. 1 and 3A-14. Inaddition to banks or other funding sources or intermediary services suchas PayPal® can be used for merchant accounts. The merchant 52 thenprovides information used by the system to create and load funds ontoVPANs. In preferred embodiments, the system knows the average saleamount, the number of transactions per week/month, the frequency ofvisits, and the gross margin of a typical visit in order to best servethe merchant. The system then sends the merchant 52 the paymentprefix(es), or merchant codes(s), which are based on the range of theVPANs used for this merchant for transactions at that merchant and whichmust be combined with the payment suffix(es), or checkout codes in orderto create a complete VPAN that then is presented on the behalf of theconsumer for payment authorization. Furthermore, as described below, aVPAN may be associated with a coin. The coin can be used to represent ortrack all the accounting procedures to be completed in relation to apurchase, such that the coin is balanced after all the accounting stepsare completed.

After both the consumer and merchant have registered with the system,the system may then be used to allow the consumer 41 to pay for goods orservices or may also be used to present offers to the consumer which maybe redeemed through a transaction using the system. As shown in step 44,the consumer checks in or is detected in a participating merchantlocation. This can be accomplished by any known or future mechanism,such as by having the consumer send a text or SMS message to the system,having the user activate an app on a smart phone that reads a bar codeor Quick Response (QR) code at the merchant location, using a geolocation or geo fencing feature or a phone or other mobile device thatdetects the consumer's location, social networking, Bluetooth, wireless,or any other mechanism to alert, detect and/or verify the consumer'slocation. This location can be set in any number of ways. The service,while not limited thereto, includes embodiments of three ways. Thecheckout code can be requested for a merchant by the subscriber, for animminent visit. Alternatively, a checkout code may be automatically sentto a subscriber device once the device is “detected” entering alocation. Also, a hybrid of these two approaches is possible, where asubscriber has already entered an establishment and desires repeatbusiness. The person can then request an additional checkout code for adevice where context or location awareness is already established. Toaccommodate transaction inquiries or to facilitate returns/exchanges,the checkout code and mobile phone number may be submitted in thecontext of the location to retrieve the transaction details.

Once the consumer's 41 presence at the merchant 52 has been determinedand where possible verified via geo location services or other meanssuch as cell tower triangulation or GPS location transmission by thesystem 49, the system then prepares for a potential purchase by theconsumer 41, as shown in step 45. The system can, preferably, take anumber of actions. The system selects a consumer checkout code to sendto the consumer 51 to be used should the consumer 41 make a purchase atthe merchant 52. As described, the checkout code, when combined with themerchant code, forms a complete VPAN that can be used to electronicallypay for a purchase. As described, in preferred embodiments of thesystem, the VPAN corresponds to a stored value card number that has beenloaded with an amount deemed sufficient to complete a transaction at themerchant. The amount can be a multiple of the average value of atransaction at that merchant, can be set based on the consumer'spurchasing history, can be selected by the consumer or merchant or canbe set using any other manner consistent with the concepts describedherein. Additionally, the value can be transferred to the stored valuecard at the time of the consumer's check in at the merchant, can bepreloaded at some predetermined time, or can be loaded to the cardaccording to some other methodology. If the card is preloaded, thecheckout code can be selected based on the amount loaded in that storedvalue card account. In addition, the consumer's payment account can beauthorized for some amount the system determines for the specificlocation. In other embodiments, an EBT card, number, or account, can bepreloaded, temporarily loaded, approved for use, etc.

Also in step 45, the system 49 can determine if there is an offeravailable for the consumer at that merchant. The offer can come from themerchant, or a related vendor, manufacturer, franchisor, anotherconsumer (gift(s)), etc. any or all of whom are considered offerproviders. If an offer or offers are available for the consumer, one ormore are selected and presented to the consumer with the checkout code.The offer may have conditions or require that certain triggers be metfor the consumer to take advantage of the offer. For example, theconsumer may be required to spend a minimum amount or to purchaseparticular goods or services to receive the benefit of the offer. Anyconditions or triggers may be included in the offer while remainingwithin the scope of the concepts described herein. The system can beused to track whether the conditions or triggers are met using thecheckout code, or the merchant modify the point of sale system in orderto verify, via automated or manual means, the triggers at the time thetransaction is completed at check out. In addition, the offer provider'spayment account may be authorized for the specific amount of the offerthat the consumer is qualified to receive.

At check out, as shown in step 46, the consumer provides the merchantwith the checkout code that was sent to them during check-in which maybe a 6 digit suffix/checkout code as described below, and in FIG.12A-12C. As described, the assigned suffix/checkout code may have theimplication of setting a value limit for the transaction since thestored value card account associated with the checkout code may bepre-loaded with a value before check out. The checkout codes arepreferably set for a reasonable upper limit of what the consumer islikely to spend at this merchant. The system may include a function forthe consumer to request more value (e.g. increase the amount they canspend on this visit), or to request that the system lower their value(perhaps for budget management reasons).

The merchant's cashier 53 enters the prefix/merchant code provided tothe merchant by the system, plus the consumer's six digitsuffix/checkout code. Expiration date, and any other informationrequired for processing, may be provided to the merchant with themerchant code. The transaction is routed to the preloaded stored valuecard that was prepared previously, such as at check-in or at thebeginning of the business day, and authorized by existing paymentprocessing systems. Settlement will similarly be managed by existingpayment processing systems in a known fashion.

In preferred embodiments, a process for combining the merchant code andcheckout code includes, in response to a request by the cashier forpayment, providing the checkout token to the cashier verbally, inwriting, by use of a code on a smart phone app, through wirelesscommunications between a smart phone and or by any other means. Thecashier then combines the consumer checkout code with the merchant codeand enters it as a “card number” in the register or on the card “swipe”terminal or via other means. The actual entry of the number can bemanual or can be through plug in application at the card terminal ormerchant register. This results in the register/terminal processing asif a physical card had been presented (though without the card-swipe),or through the actual swipe of a card that has been programmed with theVPAN.

The system 49 receives a notification (advice) that an authorization(which includes capture/completion) has been released for a given cardnumber, and amount. The system 49 will then send a receipt to theconsumer for that amount. The system of the present invention, or themerchant, can then compare the amount of the transaction to anyapplicable offers that were associated with this checkout code. If anoffer associated with the checkout code was activated and the conditionsfor the offer are fulfilled, then the amount of the offer is preferablyrequested from the merchant's offer account or alternatively anotherfunding account for which the offer provider is responsible.Additionally, the amount of the offer funds requested from themerchant's account (or other funding account) may be grossed up by anamount representing a fee for use of the system.

The system then performs a capture transaction for the total amountminus the offer amount and deducts that amount from the stored valuecard account based on the authorization performed earlier, as shown instep 47. After the value has been deducted from the stored value cardaccount using the VPAN formed by the checkout code and the merchantcode, the consumer's payment card account, loyalty account, rewardaccount, or any other funding source is charged for the total sale minusthe offer, which is charged against the offer provider's account.

After the transaction and funding are complete, method 40 moves to step48 where post transaction analysis is conducted. The system will allowthe merchant 52 to manage their offers account based on the amount offunding they provide for offers and the responses that they get.Merchants can use information collected about the purchase and theresponse to offers to create offers based on the responsiveness ofconsumers to prior offers. When the merchant decides to make additionaloffers, the merchant simply adds the value corresponding to the offer tothe merchant funding account. Similarly, other offer providers mayaccess transaction analysis data in order to provide additional offerfunding.

The payment process using the VPAN according to the present methodfollows a typical payment card scenario with respect to the stored valuecard account that was selected for this transaction, except forpotential variations attributable to the use of the system. For example,any customer service interaction from a chargeback exception dispute orfraud perspective initiates with the present system instead of eitherthe issuer of the VPAN (if different than the present system), or withthe consumer's payment card issuer. Also, the system, in addition to orinstead of the merchant, will create a proof of authorization that isretained as evidence of the transaction including location, mobiledevice, payment transaction details, and purchase receipt data.

In preferred embodiments of the system described herein, a checkout codecan be intended to be a single use account number active only for themerchant visit to which it is associated. The checkout code providescredentials for access to the system for a payments authorization, andserves as a longer term reference number for a transaction by aconsumer, specific to a particular location. A checkout code may be usedto lookup a transaction after it has been completed, given the checkoutcode and some other details such as the timeframe in which thetransaction occurred, the location, or the registered mobile phonenumber associated with the transaction.

In addition to the checkout code being specific for a given consumer ata given location, the checkout code can also be programmed to be activeonly for a certain period of time while the consumer is in the merchantlocation. Generally, this will be on the order of the third or fourthdeviation from the average visit length to the merchant, but can be setto any value desired by the system, merchant and/or offer provider. Forexample, if a coffee shop has a mean visit time of 15 min, but astandard deviation of 3 minutes, the checkout code should be active forat least 25 min.

In certain embodiments, once a checkout code has been activated, orused, it may not be re-used for a substantial period of time. Generally,the period of time between re-use of a particular checkout code shouldbe on the order of a time frame measured in years, with a time frame ofat least seven years being preferable. With respect to the actual numbergenerated as the checkout code, the generation of the checkout codeitself should not be “anticipatable”, and therefore should not besusceptible to fraudulent use via guessing or other means of providingan otherwise valid VPAN at the specific merchant location.

For the service to permit subscribers to complete transactions using thesystem described herein, individual transactions should preferably beuniquely identified. Once consumers register with the service and recordpayment method information within the secure environment of the serviceplatform, they will be able to complete a transaction with a traditionalretailer according to a unique identifier represented by the checkoutcode, the merchant code and transaction date and time.

As described, a preferred mechanism to secure these transactions wouldbe a confirmation number. In combination with the merchant code andpossibly the date and time of the transaction, the checkout code woulduniquely identify a visit by a consumer to a merchant at a specific dateand time. Once the transaction is completed and processed, a subscriberwill also be able to recall past transaction details via their mobiledevice or internet connection using an app or web browser.

Several data security enhancements may be used to ensure valid use andre-use of the checkout code, once it is generated. For example, thecheckout code will have a time-to-live, or valid time frame in which touse it. Alternatively, the checkout code will not be stored on theservice platform in its native form, to prevent unauthorized use and toenhance physical security of the database. Yet another alternativeprevents a checkout code from being re-used for the same merchant, usingany other device, for a given time period.

FIGS. 3A and 3B show embodiments of the payment workflow—FIG. 3A doesnot have an offer redemption but FIG. 3B does. As shown, FIG. 3Brequires some extra steps such as 122 (hold for expected offer) and 126(checkout code+offer details). Both embodiments complete with a captureand then presentation of the receipt.

Referring now to FIG. 3A, an embodiment of a payment workflow for asystem according to the concepts described herein is shown. Theembodiment of the workflow 90 shown in FIG. 3A does not include an offerto the consumer. Workflow 90 shows the process and message flow betweenthe different entities utilized by the system. These entities includethe consumer 91, the system 92, the virtual prepaid account issuer 93,the merchant, the merchant's acquirer 95, the system's acquirer 96, andthe consumer's issuer 97. The merchant's acquirer and the system'sacquirer are the institutions used by those entities to processelectronic payments. The consumer's issuer is the payment mechanism usedby the consumer to fund transactions, such as the consumer's creditcard, debit card, bank account, PayPal account or any other paymentsystem that could be used by the consumer to fund their purchases.Workflow 90 begins with the consumer 91 sending a check in notice 98 tosystem 92. Once the consumer 91 has checked in, system 92 sends arequest 99 for a new VPAN to virtual prepaid account issuer 93. Inaddition, system 92 sends a hold request 100 for the consumer's expectedor predicted spend to its acquirer 96, and acquirer 96 passes that holdrequest 101 to the consumer's issuer 97. Hold responses 102 and 103 aresent to system acquirer 96 and system 92, respectively, confirming thehold. Once the hold is in place on the consumer's issuer account, system92 then funds 104 the VPAN at issuer 93 with the expected or predictedspend amount, and the checkout code 105 is sent to the consumer 91. Atcheck out, consumer 91 presents the checkout code 106 to the merchant94, and merchant 94 combines the merchant code (the prefix, as describedwith reference to FIGS. 12A-12C) with the consumer's checkout code (thesuffix) to create the VPAN to be used in the transaction. The merchantthen enters the VPAN as the payment mechanism for the transaction 107which is sent to the merchant's acquirer 95. The merchant's acquirer 95sends a capture request 108 to the virtual prepaid account issuer 93which sends back a capture response 109 and sends a transaction advice110 with the actual transaction amount to the system 92. To complete thetransaction, the system 92 sends a capture request 111 to the systemacquirer 96 for the actual amount to the transaction and the systemacquirer sends a capture request 112 to the consumer issuer 97. Acapture response 113 is sent by the consumer issuer 97 to the systemacquirer 96, which is passed along 114 to system 92. System 92 can thenissue an electronic receipt 115 to the consumer 91 to complete thetransaction.

Referring now to FIG. 3B, another embodiment of a payment workflow 120for a system according to the concepts described herein is shown. Theembodiment of the workflow 120 shown in FIG. 3B does include an offer tothe consumer. The entities are the same as were described with respectto FIG. 3A, except that an offer provider 121 is added to thetransaction. As has been described, the offer provider may be any thirdparty or may be the merchant 94 or even the system 92. In someembodiments, a gift provider may be used in place of or in addition tothe offer provider 121. Functionality of providing a gift issubstantially similar to the functionality of providing an offer.Workflow proceeds as described with respect to FIG. 3A, except thatafter the hold request 100 from system 92 and the hold responses 102 and103, system 92 issues an additional hold request 122 and 123 to theoffer provider 121 for the amount of the offer. The offer provider 121then provides the hold responses 124 and 125 for the amount of theoffer. If a gift provider is present an additional hold request may beissued to the gift provider with corresponding hold request from thegift provider. Once the original spend hold and the offer hold are inplace, system 92 issues the checkout code 126 with the offer details andfunds the VPAN 127 with the expected spend plus the offer. The rest ofthe workflow is again the same as the non-offer workflow except that anadditional capture request 128 to the offer provider 121, with thecapture request 112 to the consumer's issuer 97, is sent by the systemacquirer 96. The offer provider 121 then sends the capture response 129for the offer amount alongside the capture response 113 from theconsumer's issuer. If a gift provider is present, the offer providersteps may be repeated for the gift provider.

FIG. 4 displays a possible flow chart diagram of a possible embodimentunder the current disclosure. At step 1, a consumer can download an appfrom an app store or from a retailer, and register a payment card. At 1a, a process can begin of targeting coupons for the user based onanalytics. At 2, the consumer can receive a coupon from Company A for $2off Product A. At 3, the consumer can purchase Product A with thecoupon, using either an app to pay, or the registered payment card. At4, the consumer validates the coupon by either taking a photo of thereceipt and sending or uploading the receipt to a server (ortransmitting the receipt by some other means), or by EBT transaction. At5, the consumer redeems the coupon by either getting a credit back tothe payment card, or an immediate discount. The consumer can make hischoice by selecting an option on the app screen. Other options may beavailable in other embodiments. At 6, the data regarding the consumer'spurchase and coupon use can be collected and analytics can be performedon the data. The preceding steps can be repeated for different purchasesby the same consumer, and for purchases by other consumers. Theaggregated data can give a retailer, app provider, information broker,or other party, valuable data about the results of different marketingefforts. In embodiments such as shown in FIG. 4, an EBT system can beused to collect data, or other means can be used. Paying with an app cancause data to be automatically collected as the user receives a coupon,selects an item to buy, and pays for that item via the mobile app.However, using an EBT system can allow for data collection on purchasesthat typically aren't amenable to robust data collection.

FIG. 5 is a block diagram of a possible embodiment of amerchant-consumer interaction 1100. User device 1105 may interact with adetection device 1110 upon entering a service area of a merchant. Insome embodiments, the user device 1105 may be actively searching fordetection device 1110, while in other embodiments, the detection device1110 may be actively searching for user device 1105. While only one userdevice 1105 and detection device 1110 are depicted, it should beunderstood that any number of user devices 1105 and any number ofdetection devices 1110 may be present in the service area of themerchant. Detection device 1110 may be capable of detecting the presenceof user device 1105 using various technologies, some examples of thedetection technologies include WiFi, Bluetooth, NFC, geofencing, or anycombination of these technologies or any other technology that may beused to detect the presence of user device 1105. Upon detecting userdevice 1105, detection device 1110 may inform backend 1115 of thepresence of the device at the service area of the merchant. Backend 1115may determine whether or not the user device 1105 is registered with thepayment/offer service. If user device 1105 is registered with thepayment/offer service, backend 1115 delivers a push notice to userdevice 1105. Responsive to push notice 1120, app popup 1130 may bedisplayed on user device 1105 to a user. App popup 1130 may displayoffers for the merchant or other information relevant to transactionswith the merchant. Backend 1115 may determine the forms of paymentaccepted by the merchant and generate an appropriate VPAN or otherpayment code for use during transactions between the consumer andmerchant. Backend 1115 may make this determination based upon a previousagreement with the merchant, or based upon devices installed in themerchant service area. If the user device 1105 and the merchant supportBluetooth, then Bluetooth checkout module 1135 may be used to detect theuser device 1105 based upon a Bluetooth MAC address of the user device1105. Subsequently, the user device 1105 may be used to transmit paymentinformation via Bluetooth MAC 1165 to checkout device 1185, which inturn may provide payment information, for example a VPAN, to POS 1190.In some embodiments, a Bluetooth transmitter in the checkout device 1185may be attenuated in order to reduce the transmission area of theBluetooth signal. In some embodiments, detection device 1110 andcheckout device 1185 may be housed in a single apparatus, in others,they may be housed in separate apparatuses. If the user device 1105and/or the merchant do not support or choose not to use Bluetoothcheckout 1135, then backend 1115 provides an encoded VPAN 1150 to app1160. App 1160 presents the encoded VPAN 1150, or some other paymentcode, to the checkout device 1185 via one of NFC NDEF 1175, barcode1175, or SMS 1180. Checkout device 1185 may contain one or more of a NFCcommunication device, a barcode reader, and an input device for enteringa payment number. The payment number may be a VPAN, an encoded VPAN 1150or some other payment code that may be correlated by the checkout device1185 via the backend 1115 to a VPAN. Checkout device 1185 may alsocontain a module to decode and/or verify an encoded VPAN 1150. This maybe accomplished using a hash function or other techniques used forencryption/decryption.

The merchant's existing POS, credit card, debit card, EBT, loyaltypoints, or other payment equipment and networks may be able to processthe VPAN or payment indicator similarly to the processing of moretraditional credit card, EBT, loyalty payments and the like. The systeminteracts with, secures, and accounts for all of the related paymenttransactions between the VPAN, the consumer's form of funding, the offeror gift forms of funding, and the merchant's agreed forms of paymentsvia the coin. In some cases, the payment workflows of e.g. FIGS. 3A-3B,may perform a portion of the consumer-merchant interaction of FIG. 5. Inthese cases, the checkout code described in FIGS. 12A-12C may be apartial VPAN, the complete VPAN, an encoded VPAN, a coin, a portion of acoin, or some other indicator that may be associated with the coinand/or VPAN by the backend.

FIG. 6 shows an embodiment by which an app developer can take advantageof the present teachings, including by allowing users to buy gifts forother users. Each user in the chain must accept the terms of thetransaction, but each party can gain benefit from the system. Appdevelopers and merchants can gain customers, and customers can gain easyand beneficial shopping opportunities and hopefully lower prices asdevelopers and merchants compete for their business. The presentteachings can also be utilized in any of online shopping, in storeshopping, or mobile shopping, as shown in FIG. 7. App developers caninclude retailers, marketers, EBT providers, or other parties.

FIG. 6 is a diagram of a possible embodiment of a gift giving and usagesequence 1200. Developer 1205 may develop an app related to certainmerchants or payment services. Developer 1205 may register the app witha system for managing merchant-consumer interactions. A user, Friend1210, may download the app and register a payment card or some othermethod of payment with the app and send a gift with a certain value toanother user, shopper 1215. As an example, the gift may be a dollarvalue to spend at a merchant 1220 or may be for a specific itemavailable from merchant 1220. Merchant 1220 may need to agree to termsand conditions of use of the app prior to accepting payment via the app.Shopper 1215 may visit merchant 1220 and make a purchase using the app.Friend 1210 may then be notified via the app or some other form ofmessaging that shopper 1215 has redeemed the gift.

FIG. 7 is a diagram of several possible embodiments of app screenshotsused for payments 1300, via mobile or computer. Login screen 1310 isfrom an app that may be used to access the payment system. A user mayselect from login screen 1310 whether payment is to be made in a storeor online. If an online payment is desired, pay online screen 1350 maybe displayed. The user may have been shopping online at a merchant thatutilizes the payment system. The merchant may display a bar code orother indicator to allow payment of the online purchase via the app asshown in online shopping screen 1360. The app may allow the user to scanor otherwise enter the bar code or other indicator into the app. The appmay then transmit information to the payment system which may thencommunicate with the online merchant for payment. If an in-store paymentis desired the user may select that option from login screen 1310.Depending on the capabilities of the merchant, several methods may beused for payment. Snap payment screen 1320 may be used by a merchantequipped with a barcode reader. Tag payment screen 1330 may be used by amerchant equipped with a NFC device, attenuated Bluetooth, Bluetooth LE,or other wireless payment communication device. The user may swipe ortap their mobile device on the NFC device, or other wireless paymentcommunication device in order to facilitate payment to the merchant.Tell payment screen 1340 may be used at merchants that don't have thewireless payment equipment or a bar code reader, or if snap paymentscreen 1320 or tag payment screen 1330 are not working with merchant'sequipment. Tell payment screen 1340 may display a payment code that theuser will provide to the merchant for entry into a POS or other paymentsystem.

Some embodiments under the present disclosure can comprise transactionidentifiers called coins. FIG. 8 is a diagram of the coincharacteristics. As used herein, a coin is a unique or nearly uniqueidentifier that is used to associate together a series of operationsinto a complete transaction. The coin may be specific to a set ofparticipants using a payment system associated with the coin. The coinmay also be specific to a certain time and/or location, for example thecoin may only be valid for the 30 minutes after a user enters a store.The coin may be flexible based upon rules and event driven designs thatmay be configured to support multiple use cases. Further the coin maycontractually bind together one or more of participants, merchants,locations, and funding accounts. At step 1410, a coin may be generated.Coin generation may include one or more of the following: registeringparticipants that may use the coin, validating funding accounts that maybe used to fund the coin, establishing rules for a transactionassociated with the coin, generating invites for usage of the coin, andnotifying recipients of the coin. At step 1420, a coin user may visit amerchant. When a coin user visits a merchant that supports payment viacoin, a VPAN may be created and issued for use with the coin;transaction rules of the merchant and payee may be validated; the VPANmay be funded from the previously associated funding accounts; and theuser may be presented with a checkout code. At step 1430 a user checksout using coin or a VPAN associated with the coin for payment. Thecheckout may be conducted as a typical POS or EBT transaction. Dependingon the devices available at the merchant, the VPAN associated with thecoin may be transmitted wirelessly, scanned by a bar code reader, orverbally given to a cashier or other salesperson at the POS.Participants in the transaction may be notified via message of thetransaction, and the recipient may be notified of receipt of payment. Atstep 1440, the coin transaction is settled. As part of settlement, fundsmay be acquired from the participants in the transaction, such as EBTproviders or participators, credit card companies, and others. The VPANassociated with the coin may be reset, and transaction data associatedwith the transaction may be stored.

FIG. 9 is a block diagram of one possible embodiment of coin basedpayment operations 1500. When a payment request or payment instruction1530 is received, a coin 1505 may be created. Payment instructions 1530may be received at an application programming interface (API) 1535. Anoperations list 1510 may be associated with coin 1505. API 1535 mayinteract with coin 1505 and operations list 1510. Operations list 1510may comprise one or more payment operations that are required in orderto complete the payment instructions 1530. Each payment operation isassociated with a payment conduit 1515. There may be 1 to n paymentoperations each corresponding to a payment conduit 1515. For example, afirst payment conduit may be related to a consumer requesting funds fromthe consumer's issuer. A second payment conduit may be related to anoffer from an offer provider. A third payment conduit may be related toa gift provided from a third party to the consumer via a gift cardprovider. A fourth payment conduit may be related to the merchant'sacquirer for receiving payment. Log/ledger/workflow 1525 tracks thecompletion of payment operations in the operations list 1510. Processingengine 1520 may monitor or cause payment operations to execute. At thecompletion of all the payment operations in the operations list 1510,the coin will be balanced from an accounting standpoint.

Another embodiment can proceed as follows. A customer visits a retailstore of Brand X. Wireless sensors located at the store detect thepresence of the customer's mobile device, which has been set to allowpush notifications from Brand X. As Brand X's servers realize that thecustomer is located in the store a notification can be sent to thepayment processing company. The payment processing company creates aVPAN for the customer to use when checking out of the store. Brand X cansend a coupon, such as 15% off of shirts, to the customer's mobiledevice. The customer can click on the offer. The customer can shop asnormal, choosing various products, and in this case, several shirts. Inpreparing to check out, the customer can select the money source to useto fund the VPAN one time digital payment card. In this example, thecustomer chooses to use loyalty points, while the POS device is acustomer tracking embodiment (similar to EBT). The customer, atcheckout, provides the cashier with mobile device so that it can bescanned. The visual code provided, either a digit string or a visualcode such as a QR code or bar code, provides the VPAN for payment aswell as any offers/coupons, such as the 15% off coupon of this example.Using the EBT system, an image or copy of the receipt is sent to theretailer so the retailer can study the customer's buying habits. Onereceipt may not be very valuable, but multiple receipts over time, andmultiple receipts across multiple customers will be very valuable in theaggregate.

FIG. 10 shows another possible embodiment of a VPAN payment system underthe present disclosure. System 1000 allows customers to choose from avariety of funding sources 1004 (drawing from specific funding sourcessuch as sources 1002) and to complete the payment in a format desired orallowed by a retailer. To allow the consumer to use a payment method ofchoice, a VPAN is created that matches the retailer's accepted payment.The format of the VPAN can take a variety of forms, the preferredembodiment will be a 16 digit number, similar to credit cards (seenbelow in FIGS. 12A-12C). Various other length or formats can be used. AVPAN for a customer to use will preferably be made substantially priorto the customer entering a given store. When a customer downloads andinstalls an application, and possibly selects merchants, a group ofVPANs may be created that are meant to be used in the future.Alternatively, a user's mobile device may be programmed to recognize (orbe recognized) by sensors at a merchant's location. Options for thisfunctionality could be Wi-Fi or Bluetooth, or other sensors. When acustomer enters a store, the sensors may recognize the customer, reportthe customer's location to a remote server or monitoring station, and aVPAN may be created for the customer to use if a purchase is made. Asdescribed, the VPAN payment system can resemble a one-time use digitalcard 1010. The system can fuse together multiple money sources 1002,1004 into a one-time use digital card for every purchase. Thetransaction can be carried out at a point of sale (POS) location 1012.POS 1012 can comprise a Bluetooth module connected to via a smartphone,another wireless connection, or other means of communication. A mobileapplication, computer, software program, or other device 1020 can directa consumer's interaction with POS 1012 and any backend servers orsoftware. A retailer or other service provider may create an open orcustom user experience 1006 for the user. Application 1020 can deal withmultiple retailers, marketers, and other parties. Terms and conditions1008, or other contractual matters, can differ from transaction totransaction. In other embodiments, an application may be created withterms and conditions that cover all transactions carried out, regardlessof retailer. FIG. 11 shows another possible embodiment similar to FIG.10, except that the system 1100 is more focused on a system comprisingEBT technology. As discussed above, EBT systems can comprise mechanismsfor approving, recording and analyzing purchases.

Referring now to FIGS. 12A-12C, embodiments of the construction of aVPAN usable with the present system and service is described in greaterdetail. FIG. 12A shows a typical payment card account number used by theVisa/Mastercard processing systems. In a preferred embodiment, anaccount number 20 is 16 digits long and is formed by a leading six digitissuer identifier (BIN) 21 that identifies the bank or financialinstitution that issued the card. While a 16 digit number is shown, anynumber of digits can be used to create a VPAN according to the conceptsdescribed herein. The BIN 21 is followed by a nine digit account number22 for the particular consumer/card and a one digit LUHN check value 23that allows the processor to verify that the account number is valid.

FIG. 12B shows one embodiment of a VPAN according to the conceptsdescribed herein. The VPAN in this embodiment is a sixteen digit accountnumber 25 processable by existing payment card payment processingsystems found at most merchants. The VPAN is formed from two parts. Thefirst portion, or prefix 26, is the merchant code and can be 10 digitsformed from the six digit BIN 28 and a four digit system number 29assigned by the present system. The second portion, or suffix 27, is thecheckout code and is formed by a five digit number plus a LUHN checkvalue 30. During a transaction, such as in e.g. FIGS. 1, 2, and 3A-3B,the prefix and suffix can be combined at the time of a transaction toform a payment card account number usable by the merchant to process thetransaction.

FIG. 12C shows an alternate embodiment of a VPAN according to theconcepts described herein. VPAN 32 is formed by a six digit prefix 33consisting of the BIN 35 and a 10 suffix 34 that is the consumer tokenalso referred to as the checkout code and LUHN value 36. While FIGS. 12Band 12C show two embodiments of a VPAN, one skilled in the art willunderstand that there are any number of ways to form a VPAN where aportion of the VPAN is given to the merchant and the remainder of theVPAN is given to the consumer, where the VPAN is formed by combining themerchant portion with the consumer portion in some manner. Further, theVPAN may represent a stored value account that is particular to thismerchant or is in some other fashion unique. Other divisions of theprefix and suffix may also be used in order to optimize processing tospecific card ranges including dividing payment card account numbersinto more than two constituent parts. This includes handling differentcard number sizes such as for 13-digit VISA® cards, 15-digit AmericanExpress® Cards and Diner's Club® Cards, EBT card numbers, and any sizeof other commonly used or proprietary card numbers.

In embodiments where the customer's presence is detected at a retaillocation, the merchant (or other third party) may be able to send thecustomer a notification of products on sale, coupons, offers or othercommunications. If a customer enters a clothing store for Brand Y, thenBrand Y may send a 15% off coupon, for example. If a customer enters agrocery store, then a yogurt company may be able to send a coupon foryogurt in the hopes the customer will choose its product. Someembodiments may even be able to track a customer's location within astore and target advertisements or offers to a customer's location: nearthe produce, deli, pharmacy, etc. In the embodiments described above,the retailer, merchant, seller, or advertiser would like to havemeasurable evidence of how effective their advertisements or marketingefforts were. To provide such functionality, the system can beimplemented to process the transaction using the EBT payment process andthereby capture a receipt of the entire transaction involving a VPAN andreport it to the retailer/merchant/advertiser/etc. Such reporting willcapture the customer's entire shopping cart and will have to be donewith the permission of the customer. Permission can be obtained, forexample when the customer installs a mobile application on their mobiledevice.

Various embodiments of the EBT system can be combined with VPANfunctionality. For example, when a customer checks in at a retailer(either automatically or manually), the system can send a request to thesystem acquirer for a hold on funds for an expected spend amount. Thesystem acquirer sends a hold request to the customer's issuer. Aresponse is sent from the issuer to the acquirer and then to the system.The virtual prepaid issuer then funds the VPAN, and a checkout code isprovided to the customer. The customer presents the checkout code to theretailer, and VPAN information is sent to the retailer's acquirer. Acapture request is sent from the retailer's acquirer to the prepaidissuer. A capture response is sent to the system acquirer and then tothe consumer's issuer. A response goes from the consumer's issuer to thesystem acquirer and the capture is sent to the system.

FIG. 13 displays a possible method embodiment 1300 under the presentdisclosure. At 1310, a notification is received that a mobile deviceassociated with the consumer is at a location. At 1320, the identity ofthe consumer is confirmed by receiving data from the mobile device. At1330, a VPAN (virtual payment account number) is formed, wherein thevirtual payment account number is associated with a coin, the coinacting as an identifier for a transaction between the merchant andconsumer and is specific to the payment transaction. At 1340, paymentauthorization information is sent to the consumer's mobile device toallow the consumer to initiate a payment transaction with the merchant,wherein a point of sale terminal is used to process the paymenttransaction using the authorization information at the request of theconsumer, wherein the authorization information is associated with thevirtual payment account number and the virtual payment account number isused by the merchant as a mechanism for payment using an EBT paymentprocessing system.

FIG. 14 displays another possible method embodiment 1400 under thepresent disclosure. At 1410, a mobile device is detected at a location.At 1420, the identity of the mobile device user is verified. At 1430, aVPAN is formed that is related to a coin and for payment information forthe mobile device. At 1440, the location is associated with coupons,offers, or payment information. At 1450, the coupons or offers are sentto the mobile device. At 1460, at least a portion of payment informationis sent to the mobile device. At 1470, payment initiation is receivedfrom the mobile device at a POS terminal. At 1480, purchase informationis sent to an EBT server. In some embodiments, the EBT server mayprovide approval for the purchase. At 1490, payment information isreceived from the mobile device.

Although the present invention and its advantages have been described indetail, it should be understood that various changes, substitutions andalterations can be made herein without departing from the spirit andscope of the invention as defined by the appended claims. Moreover, thescope of the present application is not intended to be limited to theparticular embodiments of the process, machine, manufacture, compositionof matter, means, methods and steps described in the specification. Asone of ordinary skill in the art will readily appreciate from thedisclosure of the present invention, processes, machines, manufacture,compositions of matter, means, methods, or steps, presently existing orlater to be developed that perform substantially the same function orachieve substantially the same result as the corresponding embodimentsdescribed herein may be utilized according to the present invention.Accordingly, the appended claims are intended to include within theirscope such processes, machines, manufacture, compositions of matter,means, methods, or steps.

What is claimed is:
 1. A system for allowing a consumer to complete apayment transaction using a payment account of the consumer with amerchant at a merchant location, the system comprising: a detection unitoperable to detect a mobile device associated with the consumer; aremote server in communication with the detection unit, the remoteserver used to verify an identity of the consumer using the mobiledevice and to form a virtual payment account number, the remote serverfurther operable to send payment authorization information to the mobiledevice; and an EBT point of sale terminal used to process the paymenttransaction at the request of the consumer, wherein the virtual paymentaccount number is received by the EBT point of sale terminal from theremote server and is associated with the payment authorizationinformation; wherein the system processes the payment transaction usingthe virtual payment account number as a mechanism for payment using anEBT payment processing system for the purpose of identifying each itempurchased by the consumer, further wherein the identity of the itemspurchased by consumer is sent to a remote application server separatefrom the point of sale terminal and associated with the consumer usingthe virtual payment account number; and wherein the payment account ofthe consumer is a non-EBT payment account.
 2. The system of claim 1wherein the EBT payment processing system saves one or more data pointsrelated to the payment transaction.
 3. The system of claim 2 wherein theone or more data points comprises a list of items purchased.
 4. Thesystem of claim 1 wherein the remote server is configured to present theconsumer an offer redeemable at the merchant.
 5. The system of claim 1wherein the remote server is configured to prefund the virtual paymentaccount number with funds expected to be sufficient to cover the paymenttransaction.
 6. The system of claim 1 wherein the virtual paymentaccount number expires after a predetermined amount of time.
 7. Thesystem of claim 2 wherein the one or more data points comprises couponinformation.
 8. The system of claim 2 wherein the one or more datapoints comprises consumer information.
 9. A method of allowing aconsumer to complete a payment transaction using a payment account ofthe consumer with a merchant at a merchant location, the methodcomprising: receiving a notification that a mobile device associatedwith the consumer is at a location; verifying an identity of theconsumer using the mobile device; forming a virtual payment accountnumber, wherein the virtual payment account number and the paymentaccount of the consumer are associated with a coin, the coin acting asan identifier for a transaction between the merchant and consumer and isspecific to the payment transaction; and sending payment authorizationinformation to the consumer's mobile device to allow the consumer toinitiate a payment transaction with the merchant; wherein a point ofsale terminal is used to process the payment transaction using thepayment authorization information at the request of the consumer,wherein the payment authorization information is associated with thevirtual payment account number and the virtual payment account number isreceived by an EBT point of sale terminal from a remote server and usedfor payment using an EBT payment processing system for the purpose ofidentifying each item purchased by the consumer, further wherein theidentity of the items purchased by consumer is sent to a remoteapplication server separate from the point of sale terminal andassociated with the consumer using the coin; and wherein the paymentaccount of the consumer is a non-EBT payment account.
 10. The method ofclaim 9 further comprising receiving one or more data points related tothe payment transaction from the EBT payment processing system.
 11. Themethod of claim 10 wherein the one or more data points comprises a listof items purchased.
 12. The method of claim 10 wherein the one or moredata points comprises consumer information.
 13. The method of claim 9further comprising presenting the consumer an offer redeemable at themerchant.
 14. The method of claim 9 further comprising prefunding thevirtual payment account number with funds expected to be sufficient tocover the payment transaction.
 15. The method of claim 9 wherein thevirtual payment account number expires after a predetermined amount oftime.
 16. The method of claim 10 wherein the one or more data pointscomprises coupon information.
 17. A system for allowing a consumer tocomplete a payment transaction using a payment account of the consumerwith a merchant at a merchant location, the system comprising: adetection unit operable to detect a mobile device associated with theconsumer; a remote server in communication with the detection unit, theremote server used to verify an identity of the consumer using themobile device and to form a virtual payment account number, the remoteserver further operable to send payment authorization information; andan EBT point of sale terminal used to process the payment transaction atthe request of the consumer, wherein the payment authorizationinformation is received by the EBT point of sale terminal from theremote server; wherein the system processes the payment transactionusing the virtual payment account number as a mechanism for paymentusing an EBT payment processing system for the purpose of identifyingeach item purchased by the consumer, further wherein the identity of theitems purchased by consumer is sent to a remote application serverseparate from the point of sale terminal and associated with theconsumer using the virtual payment account number; and wherein thepayment account of the consumer is a non-EBT payment account.
 18. Thesystem of claim 17 wherein the EBT payment processing system saves oneor more data points related to the payment transaction.
 19. The systemof claim 18 wherein the one or more data points comprises a list ofitems purchased.
 20. The system of claim 18 wherein the one or more datapoints comprises coupon information.